原因揭秘！为什么选择 Pulsar 而非 Kafka ？

🎙️阅读本文需要 5 分钟

作者：Chris Bartholomew

前段时间，我在一篇博客中提到了《选择 Pulsar 而不是 Kafka 的 7 大理由》。之后我一直在准备一份比较 Kafka 和 Pulsar 的详细报告，并一直与 Pulsar 开源项目的用户交谈，同时也与我们托管的 Pulsar 服务 —— Kafkaesque (https://kafkaesque.io/) 的用户交谈。

我发现上一篇文章中我遗漏了一些原因。所以，我特地写了本篇后续，进行补充。

在补充之前，我们先来快速回顾一下上一篇文章中提到的 7 个原因：

• 流式处理和队列的合体。Kafka 或 RabbitMQ 在单个平台上都只能处理其中一种方式。而 Pulsar 就像一个合二为一的产品，可以同时处理实时流和消息队列。
• 支持分区，但不是必需的。如果只需要一个主题，可以使用一个主题而无需使用分区。如果需要保持多个消费者实例的处理速率，也不需要使用分区。
• 分布式的日志。Pulsar 日志是分布式的，可以水平扩展。因此不会保存在单台服务器上，任何一台服务器都不会成为整个系统的瓶颈。
• 无状态的 broker。云原生应用程序开发的理想场景，数据的分发和保存相互独立。
• 原生支持跨地域复制，而且配置简单。无论是全局分布式应用程序还是灾备方案，任何人都可以通过 Pulsar 搞定。
• 稳定的表现。基准测试表明，Pulsar 可以在提供较高吞吐量的同时保持较低的延迟。
• 完全开源。不论是与 Kafka 相似的特性，还是 Kafka 没有的特性都是开源的。

以上便是之前提到的 7 个原因。如果你想了解关于以上几点的详细内容，可以查看开头提到的文章。这些原因似乎已经很多了，但是我发现了更多。

>>> 多租户处理 <<<

上一篇文章中，我应该多谈谈多租户。Pulsar 对多租户的支持是一个很重要的特性。在企业中，消息基础架构会被多团队、多项目使用。为每个团队（项目）分别维护一个独立的消息系统集群代价过高且难以维护。

Pulsar 可以有多个租户，这些租户可以有多个命名空间，以保持内容顺序。再加上每个命名空间的访问控制、配额、速率限制等，可以想象，将来我们可以只使用一个集群就能处理多租户问题。其实不仅我们考虑到这个问题，Kafka 也会考虑。在 Kafka 改进建议（KIP）KIP-37 中可以看到与此相关的内容。这个问题已经讨论了一段时间了。

>>> Quorum 复制 <<<

接下来，我会讲到很多细节。要想确保消息不丢失，消息传递系统会配置每条消息生成 2 或 3 个副本，以防出错。Kafka 使用 follow-the-leader 模型来实现这一点。Leader 存储消息，而 follower 复制 leader 上的消息。

一旦有足够多的 follower 确认已经完成了复制，Kafka 就“高兴”了。Pulsar 使用 Quorum 模型。它把消息发送给一堆节点，一旦有足够多的节点确认它们已经接收到消息，Pulsar 就很“高兴”。

Quorum 复制更加民主，没有这种 leader-follower 层次结构。所有选票均等时，多数胜利。但这与技术无关。重要的是，随着时间的推移，Quorum 复制倾向于提供更一致的行为。

这或许可以解释为什么 Pulsar 具有更一致的延迟性能。如果你想了解关于 Kafka 和 Pulsar 延迟的详细信息，请查看我的这篇博客（文章很长，别说我没提醒你哦）。

事实上，Kafka 也一直在考虑使用 Quorum 复制来改善延迟一致性。关于此，可以查看 KIP-250 中的讨论。

>>> 分层存储 <<<

像 Kafka 这样的流处理系统，其一大优点在于它能够重放已经被消费的消息。如果你第一次见到就很喜欢这些消息，则可以进行重播以更正某些内容，或围绕它们构建新的应用程序，这也是很有趣的。

如果你非常喜欢这些消息，想把它们永远保存下来，那该怎么办？比如，如果你在做事件溯源。这听起来很不错，但永久可是一段很长的时间，而且永久存储消息也可能很贵，特别是存储在高性能固态硬盘上。这些硬盘需要维持消息系统保持良好的运行状态。

如果能把那些旧消息（那些以后可能会再用到的消息）转移到相对便宜的存储解决方案中，是否可行呢？如果可以使用像 Amazon S3 存储桶这样廉价的云存储，那岂不是很棒吗？你可能已经猜到我要说什么了。

借助 Pulsar 分层存储，你可以把那些旧消息自动推送到几乎无限的、廉价的云存储中，然后像检索新消息一样执行相关操作。我敢打赌，Kafka 希望拥有该功能。没错，他们会的。在 KIP-405 中可以看到相关讨论。

>>> 端到端加密 <<<

显然，安全是很重要的，谁都不希望信息安全被偷窥。当然，你会在客户端和消息传递系统之间使用 TLS（在传输过程中加密）。这样做时，消息传递系统必须解密该连接，以便了解客户端想要表达的内容。

然后，它把未加密的消息保存在磁盘上。当然，你会坚持对磁盘进行加密，这样即使磁盘被偷，消息仍然是安全的（静态加密）。但在这两种情况下，消息传递系统都需要有数据的密钥。如果不是这样，那就是在处理一大堆莫名其妙的天书。

许多情况下，这种级别的加密已经足够好了，但是如果你想要确保没有人可以偷窥你的消息，则需要进行端到端加密。生产者在发送消息之前使用与接收消息的使用者共享的密钥对消息进行加密。当消息保存在消息系统的磁盘上时，就会被加密，而消息系统没有密钥。消息传递系统可以完成它的工作，但是你的消息对于消息传递系统来说是就像天书一样，所以是十分安全的。

Pulsar 可以在其 Java 客户端中进行端到端加密。Kafka 一直在 KIP-317 中讨论这一操作。

>>> Broker 平衡 <<<

Pulsar broker 是无状态的。组件无状态是件非常棒的事情，当一个组件过载时，你可以添加另一个组件来处理负载。当新客户端连接时，可以将它们定向到新实例。但这并不能帮助到第一次被重载的实例。你需要将一些工作从重载实例转移到新的实例上。换句话说，需要重新平衡负载。

Pulsar 会自动进行 broker 负载平衡。它监视 broker 的 CPU、内存、网络（不是磁盘，我提到的代理是无状态的）的使用情况，并调整负载以保持平衡。这意味着你不需要在单个 broker 热点时扩容 broker 集群，除非 broker 集群服务能力到达上限。

你也可以使用 Kafka 进行代理负载平衡。但是，你必须多安装一个程序，例如 LinkedIn 的 Cruise Control。或者也可以使用 Confluent 的负载平衡器工具（这款工具是需要付费的）。

>>> 社区和生态系统 <<<

有人批评我没有提到 Kafka 社区和生态系统的规模和丰富程度。这个批评很中肯。在社区和生态系统类别中，Kafka 确实比 Pulsar 做得好。作为一个开源项目，Kafka 已经开创了 5 年，所以它有一个更大的社区，有更多相关的项目，并且在 Stack Overflow 上有更多相关的问题与答案。

随着大家不断贡献新的组件和周边集成，Pulsar 社区日益发展壮大，Slack 社区的小伙伴们都很友好，也乐于助人。我还想补充一下：Pulsar 在许多方面受到 Kafka 的启发，并且站在了巨人 Kafka 的肩膀上。Kafka 项目和社区值得称赞与尊重。有时候听起来像是我不尊重 Kafka，其实我很尊重 Kafka，我只是对 Pulsar 更有好感罢了。

>>> KAFKA 的合理替代品 <<<

在这篇文章和上一篇文章中，我列举了12 条选择 Pulsar 的理由。更酷的是，我发现随着对 Pulsar 了解的加深，我总能找到新的理由。因此，我可能还会写第三篇和这个主题相关博客。敬请关注。

我认为 Pulsar 是 Kafka 的合理替代品。Pulsar 支持 Kafka 的大部分功能，而且 Pulsar 有更多优势（目前我列举了 12 个）。了解 Pulsar 的人越多，它的发展势头就越大。如果你正在评估流和/或队列系统，考虑一下 Apache Pulsar 吧。

想要随时掌握 Pulsar 的研发进展、用户案例和热点话题吗？快来关注 Apache Pulsar 和 StreamNative 微信公众号，我们会在第一时间和您分享 Pulsar 的一切。

👇🏻点击「阅读原文」可查看英文版